Motivation

Feedback from the team is that "RewriteRule" introduces vocabulary ("rule") that's at odds with the existing pattern/template/visitor/recipe terminology. The API should build naturally on CSharpPattern and CSharpTemplate without introducing new top-level concepts.

Examples

// Simple — no visitor class needed:
var expr = Capture.Expression();
return CSharpPattern.Expression($"Console.Write({expr})")
    .RewriteTo(CSharpTemplate.Expression($"Console.WriteLine({expr})"))
    .ToVisitor();

// In a custom visitor with TryOn:
var rewriter = CSharpPattern.Expression($"{x} == null")
    .RewriteTo(CSharpTemplate.Expression($"{x} is null"));
return rewriter.TryOn(Cursor, binary) ?? binary;

Summary

• Add CSharpPattern.RewriteTo(CSharpTemplate) returning a new Rewriter class
• Rewriter has TryOn(), ToVisitor(), and static CreateBlockFlattener<P>() — same implementation as the old RewriteRuleImpl/RewriteRuleVisitor
• Remove IRewriteRule interface and RewriteRule static factory class
• Rename RewriteRuleTests.cs → RewriterTests.cs and update all recipe implementations

Test plan

• All 18 RewriterTests pass
• TemplateApplyTests.AttributeRenameViaRewriteRule passes
• dotnet build succeeds with no errors